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PROGRAMMINGRy 


Il good programmers need 

to be part-time psycholo- 

gists. The reason? When 

creating user interfaces, 
you have to have the technical skill 
and the equipment to implement 
your ideas; but without an under- 
standing of how users work, those 
ideas will be useless. And under- 
standing how users work — in the 
broadest possible sense — is called 
psychology. 

No, I’m not going to launch 
off into another discussion of user 
interfaces, important though that 
topic is. The time has come to 
consider overload. 

One of psychology’s early 
phases was based on communica- 
tions theory. It viewed the human 
processor as an information chan- 
nel, studying the channel’s capac- 
‘ty and the effects of noise on 
signal processing. The exact de- 
tails aren’t important, but what is 
significant is the statement that 
humans have a limited data chan- 
nel. 

One of the nicest and simplest 
results in this area is the ‘magic 
number seven’. After lots of ex- 
periments, it was discovered that, 
on average, humans can manage 
to keep in their short term memo- 
ries seven items of information. 
The variation observed in the ex- 
periments was such that a more 
accurate statement of memory 
capacity is seven items, plus or 
minus two. 

What has this got to do with 
programming? As a programmer, 
you are subject to the same infor- 
mation processing limits as any 
_lesser mortal. This is the reason 

1y all programming methods 

endeavour to hide the complexity 
of a program in a layered struc- 
ture. In modular programming, 
programs are built up out of small 
chunks of code in the form of 
modules. Each module should be 
small enough to fit into the ‘seven 
plus or minus two’ category. 
Equally, each layer of subroutines 
should be confined to the same 
size limits, so that every layer can 
be easily understood. 

I have come across program- 
ming methods, some well known 
and some very localised, that stress 
the ‘seven’ part of the rule rather 
too much. For example, a Fortran 
project I was involved in had the 
arbitrary limit of no more than 
seven lines of active code per sub- 
routine — the project leader was 
brother to Genghis Khan and a 
fine warrior, but he applied rules 
rather too literally for my liking. 

In some more elaborate design 
methods, such as Yourdon/De 
Marco, you will find people con- 
verting guidelines such as ‘no more 
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As if trying to understand computers wasn’t hard 
enough, Mike James thinks programmers 
need to understand people, too 


than around seven 
bubbles in a struc- 
ture chart’ into a 
similarly exact law. 
Now you know 
the origin of the 
magic number 
seven that crops up 
so often, and you 
also know that 
seven could just as 
well be five or nine. 
In fact, the situa- 
tion is much vaguer 
than even these 
loose numbers 
would suggest. I 
have yet to come 
across a ‘seven’ rule 
in object-orien- 
tated program- 
ming, but it’s only 
a matter of time. 


Too much 
too fast 


If there is a lesson 
to be learned from 
seven, then it is not 
to overestimate 
yourself or your 
colleagues. If you 
write a nice little 
subroutine today, 
imagine the dolt 
who will have to 
maintain it—clearly 
a lesser brain who 
will never under- 
stand your master- 
ful coding. If you 
expect this, then 
plan for it! Make 
your code easy 
enough for the dolt to cope with; 
who knows, that dolt may be you. 

The magic number seven has 
had its influence on programming 
methods, but it has had less influ- 
ence on the user interface, where it 
is just as important. Have you ever 
seen one of those multiscreen pres- 


entations? Ever wondered why such 
technical wizardry hasn’t really 
caught on? The answer is that it 
takes a lot of processing power to 
cope with a multiscreen bombard- 
ment, and sadly, the vast majority 
of people just can’t cope. Indeed, 
many multiscreen producers can’t 
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cope themselves, as demonstrated 
by the tendency to repeat the same 
graphic over several screens. No, 
the average viewer likes a nice, 
simple, single thread storyline — 
with one image following another, 
preferably in the correct time se- 
quence. 


Think for a moment what this 
means for advanced programming 
applications like hypertext, multi- 
media and GUIs. Hypertext and 
multimedia are clear examples 
where the human processing chan- 
nel is threatened with imminent 
swamping by excess information. 
In the case of hypertext, the 
swamping is a drawn-out sort of 
affair, as the user follows multiple 
threads of information and for- 
gets what the original enquiry was 
all about. In the case of multime- 
dia, the swamping can be immedi- 
ate — more like a tidal wave of 
information. To watch onscreen 
animated graphics and try to read 
text and listen to the audio tracks 
all at once can be thrilling, but it 
can also send the innocent who 
actually try to cope with the infor- 
mation into terminal overload. 

Finally, and most importantly, 
consider GUIs. Now you might 
think that GUIs are about as 
rarefied an atmosphere as hypertext 
and multimedia, but that is begin- 
ning to change. The new Windows 


high-level languages, such as 
WinBasic and the latest Turbo 
C++, make it possible for just 
about any programmer to dabble 
in GUIs almost immediately and 
without any thought to what makes 
a good GUI interface. If you go to 
Windows the hard way, via the 
SDK, then at least you get a copy 
of IBM’s SAA design guide thrown 
in; with the new easy options, 
you're left to your own devices. 
What I am getting at is that until 
now, most of the GUI interfaces 
that we have been exposed to have 
been designed with some degree of 
care. In the very near future, it will 
be possible for programmers to 
use dialog boxes and radio but- 
tons without the need to plan what 
the entire interface will look like. 
I can recall some poor GUI in- 
terfaces that I’ve had to use in the 
past, but now the power to make 
a mess of it is open to all of us. 


One at a time, please 
There are two ways in which ac- 
knowledging the human informa- 
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tion processing limit can help us 
produce better GUI interfaces. The 
first is to recognise that, no matter 
how complicated the screen gets 
and no matter how many windows 
are on view, the focus of attention 
cannot encompass more than one 
or two things at any moment. In 
the same way that you shouldn’t 
nest control structures too deeply 
in a subroutine, you shouldn’t nest 
dialog boxes or windows too 
deeply. It is better to think in 
terms of a single focus of attention 
within your application. Of course, 
if the user chooses to open multiple 
applications and so split the focus, 
well, that’s up to them. Menus in 
GUIs are no different from menu 
structures in any program; the 
rules are that you must keep them 
structured by function and keep 
them balanced. A more subtle 
problem is entrapping the user by 
leading them down a sequence of 
selections that cannot be back- 
tracked in a single operation. This 
should be avoided at all costs — it 
is the GUI equivalent of modes. 
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If you want to see an example 
of a program that breaks these 
rules, then look no further than 
the standard Windows File Man- 
ager. Although there are things 
you can do to simplify its opera- 
tion, most users end up with it in 
a mode that allows it to spawn 
windows every time they dare to 
look at another directory. 

If you don’t use it in this mode, 
then it is impossible to look at 
more than one device at a time. All 
sensible GUI file managers make 
use of at most two windows — one 
for source and one for destination 
—and each window shows files in 
a particular subdirectory. Perhaps 
the poor design of the File Man- 
ager was to open the way for third- 
party upgrades, but this is prob- 
ably an unfair attribution of 
Machiavellian motives tr ~ 
Microsoft. On the other hand, 
there can be no better way to 
discover how the user interface 
should be than to set about de- 
signing a crippled version of a 
program on purpose... 
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